Cohesive Programming for Distributed Systems

Our work seeks to greatly simplify the programming model of cohesive distributed systems. Here, a cohesive distributed activity is one that is conceptually an individual operation, yet executes across multiple physical devices. We believe that the communications structure of a distributed program should be separable from the software engineering modularization of the program. Current distributed programming technologies do not allow these concerns to be decoupled. We propose developing a distributed programming model that allows a single program text to be executed across distributed hardware. Module boundaries within the program text need not align with hardware communication boundaries, thus allowing separation of distribution concerns from modularity concerns. 1. Distributed Systems are Often Cohesive Consider the distributed systems aspects of the following robotics system: Multiple robots patrol an area, as a fire watch. The system as a whole must perform many activities including allocating robots to areas, performing navigation, and of course actually reporting fires. These tasks are distributed in a variety of ways, some on board the robot, some to a central controller. Crucially, though, there are some tasks that are performed partly on the central controller and partly on the robots. Circumventing obstacles is one such task: Sometimes the obstacles are other robots, so the central controller, in cooperation with the involved robots, can negotiate a resolution to the conflicting robot paths. However, each of these distributed controller–robot tasks must behave cohesively, as if it was a single program. For example, the obstacle resolution task requires the fusion of the sensor data indicating an obstacle with the reported positions of the other robots. This sub-task could be decomposed into separate programs which communicate, but it would be superior from a software engineering viewpoint to maintain it as a single program, with various parts of this unified program running on the robots and the central controller. This example is by no means unique. In many distributed systems, activity that is conceptually an individual operation executes across multiple physical devices. This is true at all scales of complexity, from multi-robot systems to mobile content streaming. Even an operation as unremarkable as user input validation on a Web form is often implemented as a mix of code running in the Web browser and the Web server. Admittedly, many distributed problems naturally decompose into separate communicating modules. However, this module-per-device decomposition is not always the most suitable one. 2. Current Methods Shatter Cohesion Despite the ubiquity of distributed applications, current distributed programming models can be tedious and precarious to use. Programmers are required to express distributed operations as isolated modules, each executing on a single device, and then explicitly and painstakingly specify each interaction. Quickly, these communications details overwhelm the codebase, obscuring the development of the useful application logic. RPC systems such as XML-RPC and Java RMI do not solve this problem. They still force separation between the client and the server and require large amounts of communication code. Take Java RMI [7], for example: To develop an application that executes on two machines, a developer would create two separate programs—a client program and a server program—which share a Java interface. For the simplest case (a single method call), this adds about 25–50 lines of code overhead. More harmfully, this fractures the application logic into these separate programs. This architecture for RPC is quite common: DCE/RPC, CORBA, ONC RPC, MSRPC, Distributed Ruby, and many other systems impose this client-server split. Erlang [1] provides a less constrained model of communication. Erlang processes can send messages to arbitrary other processes, and processes can be distributed among nodes. This allows interactions beyond strict client-server style; however, Erlang still structures its code into separate modules among which messages are passed. This results in the same fragmented programming style that RPC often creates. To be fair, using module boundaries as communications interfaces is a semantically straightforward approach. Interactions across modules are, by design, well-defined and con-